Application Penetration Testing

Creators of mobile, progressive, and web applications rarely consider protecting their product in the first year. Some do not assume that someone will attack their applications, which are not their not widely known yet, and steal users’ money or data. Others are aware of the risks, but so far save on security.

When you release an application, its users must be sure that, during a cyberattack, confidential information will not fall into the wrong hands. Large amounts of data that pass through applications and are stored on servers are valuable prey for attackers. For their sake, they arrange sophisticated attacks. As hacks become more common, protection becomes a top priority.

The importance of securing fintech applications

According to X-Force Threat Intelligence Index 2020 by IBM and Hi-Tech Crime Trends 2019/2020 by Group-IB, the financial sector was again leading in terms of attacks in 2019, for the fourth consecutive year. In the annual statistics by Kaspersky Lab, it also holds its first position since 2015.

The World Economic Forum included cyberattacks in the top five global risks of 2019. In mid-2019, the Bank of England ranked them third in its rating of risks to the financial system, and by the end of the year, it had already ranked them second.

While large commercial banks are able and obliged to protect their systems and applications with the help of information security departments, small and young fintech companies do not try hard enough. And that is a bad practice because it leads to dire consequences.

Hacks with theft of cryptocurrencies

We collect statistics on incidents in the areas in which we are well versed. We track the problems of cryptocurrency exchanges and services because web apps are their key component. In most cases, it was through the applications that hackers got to the hot wallets.

In 2019, nine exchanges and one multifunctional service were hacked, with coins and tokens stolen in an amount equivalent to $177,263,000. And below are the incidents of 2020, as a result of which cryptocurrency companies and projects lost their and user assets:

Type and name	Date	Object of theft	Damage in US dollars
Altsbit crypto exchange	06/02/2020	5 types of cryptocurrencies	285,000
Trinity wallet (IOTA project)	12/02/2020	MIOTA coin	2,855,000
bzx DeFi platform	15/02/2020	ETH coin	316,000
bzx DeFi platform	18/02/2020	ETH coin	673,000
Bisq crypto exchange	07/04/2020	BTC and XMR coins	252,000
Balancer Labs DeFi project’s pool	28/06/2020	5 types of tokens	482,000
Balancer Labs DeFi project’s pool	29/06/2020	COMP token	2,300
Cashaa crypto platform	11/07/2020	BTC coin	3,124,000
	So far for 2020:		$7,989,300

Have you created a crypto application or implemented cryptocurrency acceptance into a regular app? When you announce an innovation, know that publications will attract not only the target audience but also criminals. And if you do not have time to check the release for vulnerabilities, they will definitely do it and take advantage of them.

Theft of traditional money and payment data

Hackers continue to attack banking systems and applications, although they are better protected than others. In 2020, they are targeting Asia, judging by the successful hacks. Here’s how many records with bank card data they stole in six months and put up for sale:

• 462,000 records from Indian banks
• 397,000 records from banks in South Korea and the United States
• 235,000 items from banks in Malaysia, the Philippines, and Singapore

They also steal money from financial institutions, but banks carefully hide such cases so that their reputation does not suffer and clients do not close their accounts en masse. If something reaches the media, it is very brief, without specifying the amount stolen, but with assurances that clients’ funds are safe. And the public calms down, especially knowing that banks are insured.

Fintech companies that do not belong to traditional banks are less protected. There are always vulnerabilities in electronic payment systems and mobile banking apps; if not with them, then with the third-party services that they connect. Here are some recent examples:

1. In February, cybercriminals used Paypal’s integration with Google Pay to pay for purchases in the United States from accounts of German users. Paypal representatives acknowledged the problem and paid the victims tens of thousands of euros.
2. In July, attackers stole the identity of 7.5 million users of Dave, a mobile banking app. They were able to collect such a database due to the negligence of Waydev, a provider of analytical services for Dave. Since there was no financial and confidential information, this database was leaked to the public.

Unauthorised purchases at someone else’s expense

Since 2019, hackers have begun to attack online stores and cloud services more actively than in previous years. The reasons are obvious: in e-commerce, cards are involved; for many buyers, they are linked to accounts; the clouds store terabytes of confidential information and trade secrets.

In July 2019, an incident happened that illustrates how careless application creators can be and what kind of professionals criminals are. On 1 July, the Japanese minimarket chain 7-Eleven delighted customers with the mobile payments function added to the 7pay app. Hackers were also delighted as the very next day they found a vulnerability in it, using which they got access to 900 accounts. During the day, they spent 55 million yen (about 510 thousand US dollars) from linked cards. The company had to shut down 7pay on 3 July and compensate the victims.

In March and April 2020, hackers used the outdated but still working NNID authentication to log in to Nintendo user accounts. At someone else’s expense, they bought Nintendo games and Fortnite game currency paying with cards or PayPal linked to profiles. 300,000 users were affected; the company has already reset their passwords and almost refunded the money the hackers spent.

The need to protect applications with any data

A non-fintech business owner may think that the risks are minimal if their company is not involved in storing and transferring money or processing payments. We are sorry to disappoint you: cyber thieves are interested not only in money and bank cards but in everything they can easily steal and later sell.

There will always be buyers for personal data and confidential information, for example, your company’s competitors and scammers. On the darknet, they can buy a stolen database of thousands of clients for $300 and start processing them. But for the compromised company, each record costs $152, according to a report by IBM Security. The researchers surveyed the affected companies and found a global figure: an average of 25,600 records leaked, resulting in a loss of 3.9 million US dollars.

Consequences of violating data laws

Once you allow data to be stolen or leaked, be prepared to face lawsuits and fines for violating personal data protection laws. Many jurisdictions have mandatory notification rules for data problems. Regulators require companies that have violated the processing and storage of data to inform them and customers, compensate for damage, and pay a fine.

In the European Union, the General Data Protection Regulation (GDPR) has been in effect since May 2018. In 18 months after adoption, the 28 EU states have registered 160,000 notifications of the data breach. According to them, local regulators have fined companies totalling 114 million euros (about 134 million US dollars). The GDPR provides for two types of fines depending on the severity of the violation:

1. For slight violations, a fine of up to 10 million euros or 2% of annual turnover is imposed.
2. For major violations, a fine of up to 20 million euros or 4% of annual turnover is imposed.

After Brexit, the UK is still under GDPR. At the end of 2020, it was replaced by a combined version of the EU GDPR and the old DPA 2018, which is conventionally called the UK GDPR. It also includes the same two types of fines with equivalent values in pounds sterling. In the UK, compliance with the law is overseen by the Information Commissioner’s Office.

In Russia, violation of a similar law—Federal Law No. 152-FZ On Personal Data—is still punished too lightly. For this, an administrative fine of up to 75,000 rubles (about $1020) is imposed, and this is a liability that has been toughened since July 2017. In the Russian Federation, compliance with the law is monitored by the Federal Service for Supervision of Communications, Information Technology and Mass Media.

Unfortunately, penalties do not force companies to step up their cybersecurity measures. More than 14 billion records were compromised in 2019 (twice as many as in 2018). And already in June 2020, this high score was broken. Thus, by the end of the year, the indicator is expected to double again.

Threats to messaging apps

Messaging applications have become a common form of communication; people are actively using them instead of calls and SMS. Black-hat and white-hat hackers have also paid attention to messaging applications for a long time and are regularly researching them.

During 2019, Facebook alone added 11 WhatsApp vulnerabilities found by bug hunters to the U.S. National Vulnerability Database. Below are the problems smaller companies faced in 2020:

• In March, WhisperText, which created the Whisper app for anonymous communication and exchange of secrets, learned of a security issue. It was reported through the media by independent specialists who discovered an unprotected 75 TB database with 900 million records. The database, which has been replenished since 2012, stored user aliases, personal profile data, IP addresses, and location coordinates. But the company has positioned its application as the safest place on the Internet.
• In early April, Zoom Video Communications, which created the Zoom video conferencing platform, received a bug report from an ethical hacker. The hacker described in detail how, in 25 minutes and 91,000 attempts, he brute-forced a password to someone else’s conference. There was no limit on the number of attempts in the web client, and passwords were a six-digit numeric code (this is a maximum of a million combinations).
• In mid-April, independent researchers discovered Zoom’s database for sale on darknet forums. The dump contained the credentials of 530,000 users (emails, passwords), conference IDs, host names and keys. This is not related to the password guessing bug.

By the way, setting a password for a conference appeared in Zoom because with the increase in popularity and audience, there arose a prank movement — Zoombombing. Bored during the pandemic trolls parsed links to meetings, broke in, and wreaked havoc with shock content and indecent behaviour. Strengthening the password by adding characters did not reduce their activity because these saboteurs do not brute force passwords. They get them from open sources or beg from decent participants, and then share them in their circles, planning Zoom raids.

Don’t want to face similar problems and get into the news? Hurry up to order a pentest from information security specialists before hackers carry it out without your consent.

Application vulnerabilities

Most mobile applications have a client-server architecture. Users download the client part from the store and install it on their devices with a mobile OS. The server side is a web application that interacts with a mobile client via an application programming interface (API).

Vulnerabilities are found in both the client and the server, and even between them — in the data transmission channel. If you have a web app or website rather than a mobile one, it is still useful to know about weak points on the server side or on the way to it.

Vulnerabilities in mobile apps

A study of popular mobile apps conducted by PT in June 2019 showed that 38% of iOS and 43% of Android apps had high-risk vulnerabilities. 74% of iOS and 57% of Android apps contained errors in security mechanisms; 76% of applications did not store data securely. Let’s talk about the most common vulnerabilities that require elimination from a mobile application.

Unprotected binary code

Unprotected binary code will allow attackers to reverse it to the source code, and this cannot be allowed. Imagine your application is Fort Knox, which must be impregnable. By leaving the binary code unprotected, you give everyone access to the ‘golden’ information inside, including the storage plan and security controls.

Attackers can also clone a mobile application and then upload a version with malicious code and a similar name to stores as a copy of the official product.

Connecting to an internal server

A mobile application that accesses data on a server via API calls becomes vulnerable when it does not use HTTPS for all connections. And SSL methods are left unprotected if they allow you to use a certificate, such as the insecure version of SSLSocketFactory.

Also, since basic HTTP authentication is already considered insecure, you have to protect your REST API with JWT. When accessing user account data, these tokens must be generated as part of a secure interactive login with users.

Storage location

If you store user data in unprotected places, for example, in Plist files, then someone will definitely get unauthorised access to them. It is better to store accounts and other data in the appropriate keychain: iCloud Keychain in iOS, KeyStore or KeyChain in Android. Confidential information requiring local storage should always be encrypted.

Open source libraries

Code libraries need to be constantly updated to include security fixes in time. Just be careful when updating open source libraries. They are a weak point used by hackers who inject malicious code there. Such a library is not infected until automated build processes configured to use the latest version enable it.

Lack of 2FA

The lack of two-factor authentication makes the use of the mobile application insecure, so this protection should not be forgotten. Activated 2FA can stop hackers who can guess the usual password for a user’s account. One-time passwords secure the application and ensure that it doesn’t give attackers access to the real owner’s account.

Vulnerabilities in web apps

A study of popular web apps conducted by PT in February 2020 showed that 90% of applications could be used to attack users. Unauthorised access to the application was possible on 39% of websites; 68% of applications had a data breach threat. Let’s analyse the most common vulnerabilities that require elimination from a web app.

Weaknesses of CMS

If you are using a popular content management system like Joomla or WordPress, then keep in mind that they are not completely secure. Even out of the box, they have many vulnerabilities that have to be eliminated by the owner-administrator.

Plugins installed in the CMS are also vulnerable, both third-party and official ones. The most popular and proven WordPress plugins like Yoast SEO or WooCommerce are easily hacked using XSS, and the authorisation plugin is prone to SQL injection.

Session management

Session management allows an application to identify a user for various requests. When a user tries to log in, it helps them interact with the application without having to re-authenticate.

Hackers try to break session management to bypass authentication easily. If they succeed, then they will hack the web app itself.

Attacks and methods of hacking applications

Previously, protecting a web app was limited to configuring the server and cleaning the website from unnecessary files and code chunks. At the time, there were fewer vulnerabilities, applications were simple, and user actions were predictable. Gradually, the process of protection became more complicated, as the server infrastructure developed rapidly, the code became larger and more complex, which increased the attack surface in total.

Attacks on web apps have exponentially increased in all directions and a variety of ways. Let’s list the main types of attacks and hacking methods that are used by black-hat hackers for criminal purposes and by white-hat hackers when testing the security of web apps.

Brute-force attack

During a brute-force attack, hackers work through all possible combinations hoping to guess correctly. They use it to hack applications of a critical class in order to intercept API calls and execute authorisation code without leaving a trace. This reverts the code to its original form. The attack also involves changing the mapping so that a call to API A actually calls API B, and API B can store information about bank cards on another server, collect client data, and configure itself to perform unwanted operations.

SQL injection exploitation

This is the most common way to hack web apps and websites. Most of them use the Structured Query Language (SQL) to interact with databases. It allows you to create and modify records in a database.

By doing SQL injections, hackers can break into the internal components of a web app. They consist of SQL queries via input from a client to a web app. Thus, criminals can read information from the database and use it. They can also modify the query and perform the functions and operations of the DBMS administration.

An SQL injection attack inserts SQL code into a web form in an attempt to force the application to execute it. This is how hackers can gain access to a restricted area of a website. Other SQL injection attacks can be used to delete or insert data, that is, to manipulate the database.

Cross-site scripting

Hackers also often use cross-site scripting (XSS) to hack websites. For many owners, it has become a serious threat. Only the largest websites, such as those owned by Google and Microsoft, successfully deflect XSS attacks.

XSS attackers use malicious JavaScript embedded in the links that they distribute everywhere. When a user clicks on a link, it unwittingly allows stealing information, intercepting a web session, hijacking an account, and even changing ads on the page.

To avoid XSS attacks, website owners must filter user input to remove malicious code on time.

DoS/DDoS attacks

A denial of service (DoS/DDoS) attack loads a website with a huge volume of traffic in the form of requests, causing its servers to fail. Most DDoS attacks are carried out using devices that have been compromised by malware. The owners of infected computers may not know that their PC is sending requests to someone’s website.

Cross-site request forgery

Cross-site request forgery (CSRF) involves the transmission of unauthorised commands from a user trusted by a web app. Hackers have many ways to send bogus commands, including hidden forms, AJAX, and image tags. The user does not know that the command was sent, and the website believes that the command was received from an authenticated user. The difference between CSRF and XSS attacks is that the user must be logged in and the system must identify the user as a trusted one.

DNS spoofing

This hack injects corrupted domain system data into the DNS resolver cache to redirect traffic from the website to another location. Hackers use it to send traffic from well-known trusted websites to their doorways containing malware. DNS spoofing is also used to collect traffic information.

Client-side control

This is a popular hack of a web app, in which hackers manipulate the data transmitted via the client. They hack client controls and then collect user data. Hackers find everything suitable in the web app itself, where there are hidden form fields, URL parameters, and cookies used to pass data through the client. They then try to determine the role that a particular item plays in the application login.

Who should test and protect applications

To create a quality application, you need to build a team of web designers, layout designers, front-end and back-end developers. They should have many years of experience in developing projects of various complexity: from small apps to high-load systems.

For someone to check the created application for errors and, if available, send it for revision, you need a team of testers, QC, and QA. They can be temporarily hired for a project or it can be outsourced. The testing team will check the functionality of the application and the correctness of the scripts. At the same time, code auditors rarely search for vulnerabilities.

A safety study of web and mobile applications is the competence of other professionals. Therefore, you also need a team of information security specialists, mainly information security engineers. With experience in attack and defence, they will test the application for penetration and find possible vulnerabilities.

Until they are involved, the application remains open to intruders, even if the developers did not cheat during the creation, and the testers checked it thoroughly. Information security specialists should be contacted before each stable version is released. It is advisable to conduct security audits throughout the development cycle to eliminate vulnerabilities in time.

Polygant also provides services for the development of terms of reference for information security professionals.

Penetration test

A penetration test, or pentest, is a complex but mandatory process in ensuring the security of an application. It is a simulation of attacks on application components to identify vulnerabilities that can be exploited by real cybercriminals.

Manual testing involves attempting to compromise any number of application components to detect vulnerabilities. For example, APIs, external and internal servers become its objects.

After penetration testing of the application, the results are used to fine-tune security and eliminate the vulnerabilities found.

What is included in a penetration test service

Our information security specialists conduct security testing of web and mobile applications in five stages.

Planning and exploration

First, they determine the scope of work and the purpose of the test, including the systems to be addressed. They draw up test methods to be used. They also collect information (about mail servers, network and domain names, etc.) to understand better how the target works and where to look for potential vulnerabilities.

Static and dynamic analyses

These two analyses provide insight into how the target application will respond to various intrusion attempts. First, static analysis is performed — checking the application code to assess its behaviour during operation. Tools for such analysis allow us to scan all the code in one pass. Then a dynamic analysis is carried out — checking the application code in working order. This is a more practical way to scan because it allows us to view the performance at runtime.

Gaining access

To identify possible vulnerabilities of the target, our specialists use attacks such as XSS, SQL injection, and backdoors. Then, penetration testers try to exploit these vulnerabilities by arranging privilege escalation, data theft, traffic interception, and so on. It will allow them to determine the damage that attacks can cause.

Maintaining access

The goal is to find out if the vulnerability can be used to achieve a permanent presence in the system used. It is desirable to allow the presence for such a long time that the penetration tester has time to get in-depth access. The idea is to simulate persistent advanced threats that remain on the system for months, during which intruders steal confidential information.

Results report

Finally, the penetration test results are combined into a report detailing the following:

• Vulnerabilities that have been found and exploited
• The data that has been accessed
• The time during which the pentester remained unnoticed in the system.

What methods of app security testing are used

External testing

External penetration tests are designed for resources that are hosted on the Web, for example, a web app, a website, mail and domain name servers, and even a mobile client. The goal is to access them and extract valuable data.

Internal testing

In an internal test, a pentester with access to an application behind a firewall simulates an attack disguised as an attacker. A common scenario is data theft, for example, by phishing a contingent employee.

Blind testing

In a blind test, the pentester is only given the name of the application to target. This allows the project security team to see in real time how the actual attack would proceed.

Double-blind testing

In a double-blind test, the project team, which is conventionally opposed by pentesters, has no prior knowledge of the simulated attack. As in the real case, they will not have time to build up their defences before the hack attempt.

Targeted testing

In this scenario, the pentest company works together with the project team, informing each other about their actions. This is a valuable exercise in providing the security team with feedback and an opportunity to look at the attack from the hacker’s perspective.

Penetration testing and protection services

Protecting a mobile or web application from hacking is a top priority after a product is released. It is necessary to treat it with maximum responsibility even at the beta stage because your reputation depends on it.

Imagine if banking applications with account access were easily hacked and your money was sent to a criminal. Would you use the application and, in general, the services of a bank that allowed this? Now put yourself in the shoes of the users of your application, which entered the market unsecured.

The pentest cost starts at 5000 USD. This is hundreds of times less than the losses that any company can incur due to the actions of intruders, as well as claims from customers and regulators if the activity is related to finance or data processing and storage.

Protect your application from hacking and your company from reputational risks before it’s too late. Contact Polygant, a professional team that has been searching for vulnerabilities, testing hacking scenarios, and eliminating security threats for 10 years.